Open
Conversation
|
👋 Welcome back jwilhelm! A progress list of the required criteria for merging this PR into |
|
@JesperIRL This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
irisclark
approved these changes
Mar 16, 2026
irisclark
approved these changes
Mar 18, 2026
aivanov-jdk
reviewed
Mar 18, 2026
Co-authored-by: Alexey Ivanov <alexey.ivanov@oracle.com>
Co-authored-by: Alexey Ivanov <alexey.ivanov@oracle.com>
aivanov-jdk
reviewed
Mar 26, 2026
| | Issue Type | Covers | | ||
| |:-|:----------| | ||
| | [Bug]{.jbs-value} | A [Bug]{.jbs-value} should relate to functional correctness - a deviation from behavior that can be tied back to a specification. Anything else, including performance concerns, is generally not a bug, but an enhancement. Though it's not clear-cut as a significant performance regression may be classified as a [Bug]{.jbs-value}, for example. | | ||
| | [Bug]{.jbs-value} | A [Bug]{.jbs-value} should relate to functional correctness - a deviation from behavior that can be tied back to a specification. See [Is it a Bug or an Enhancement?] | |
Member
There was a problem hiding this comment.
Suggested change
| | [Bug]{.jbs-value} | A [Bug]{.jbs-value} should relate to functional correctness - a deviation from behavior that can be tied back to a specification. See [Is it a Bug or an Enhancement?] | | |
| | [Bug]{.jbs-value} | A [Bug]{.jbs-value} relates to functional correctness - a deviation from behavior that can be tied back to a specification. See [Is it a Bug or an Enhancement?] | |
More concise?
|
|
||
| #### Is it a Bug or an Enhancement? | ||
|
|
||
| To decide whether an issue is a bug or an enhancement is not always straight forward. The basic distinction is not complex. If the detected behavior breaks the specification, it's a bug. If the intended behavior changes the specification, it's an enhancement. To make the right choice in reality, it might help to consider a few things: |
Member
There was a problem hiding this comment.
Suggested change
| To decide whether an issue is a bug or an enhancement is not always straight forward. The basic distinction is not complex. If the detected behavior breaks the specification, it's a bug. If the intended behavior changes the specification, it's an enhancement. To make the right choice in reality, it might help to consider a few things: | |
| Deciding whether an issue is a bug or an enhancement is not always straightforward. The basic distinction is not complex. If the detected behavior breaks the specification, it's a bug. If the intended behavior changes the specification, it's an enhancement. To make the right choice in reality, it might help to consider a few things: |
“Deciding” fits more naturally in my opinion.
| To decide whether an issue is a bug or an enhancement is not always straight forward. The basic distinction is not complex. If the detected behavior breaks the specification, it's a bug. If the intended behavior changes the specification, it's an enhancement. To make the right choice in reality, it might help to consider a few things: | ||
|
|
||
| - Is there a failing test? | ||
| : Provided you didn't just write the test and are doing test-driven development, a failing test is usually a sign of a bug. Something that used to work is now failing. The bug could be either in the JDK or in the test, but something is broken if a test is failing, and that should be classified as a bug. |
Member
There was a problem hiding this comment.
Suggested change
| : Provided you didn't just write the test and are doing test-driven development, a failing test is usually a sign of a bug. Something that used to work is now failing. The bug could be either in the JDK or in the test, but something is broken if a test is failing, and that should be classified as a bug. | |
| : Provided you didn't just write the test and aren't doing test-driven development, a failing test is usually a sign of a bug. Something that used to work is now failing. The bug could be either in the JDK or in the test, but something is broken if a test is failing, and that should be classified as a bug. |
Member
There was a problem hiding this comment.
Perhaps, I'd emphasise “a bug” in the end of the sentence: “…that should be classified as a bug.”
| : Provided you didn't just write the test and are doing test-driven development, a failing test is usually a sign of a bug. Something that used to work is now failing. The bug could be either in the JDK or in the test, but something is broken if a test is failing, and that should be classified as a bug. | ||
|
|
||
| - Is the existing code working as it was designed? | ||
| : If the code is doing what it was designed to do, and the design itself didn't have a bug, adapting code to changing circumstances should be considered enhancements. It's not a bug that we're not supporting a new version of an OS that didn't exist when the code was written. This includes cases where something that wasn't desired or required before has now become so. If something was deliberately left out for some acceptable reason, it would be an enhancement to add it later. |
Member
There was a problem hiding this comment.
Suggested change
| : If the code is doing what it was designed to do, and the design itself didn't have a bug, adapting code to changing circumstances should be considered enhancements. It's not a bug that we're not supporting a new version of an OS that didn't exist when the code was written. This includes cases where something that wasn't desired or required before has now become so. If something was deliberately left out for some acceptable reason, it would be an enhancement to add it later. | |
| : If the code is doing what it was designed to do, and the design itself didn't have a bug, adapting the code to changing circumstances should be considered as an enhancement. It's not a bug that we're not supporting a new version of an OS that didn't exist when the code was written. This includes cases where something that wasn't desired or required before has now become so. If something was deliberately left out, it would be an enhancement to add it later. |
To make the sentence flow more similar to that for the bug.
| : If the code is doing what it was designed to do, and the design itself didn't have a bug, adapting code to changing circumstances should be considered enhancements. It's not a bug that we're not supporting a new version of an OS that didn't exist when the code was written. This includes cases where something that wasn't desired or required before has now become so. If something was deliberately left out for some acceptable reason, it would be an enhancement to add it later. | ||
|
|
||
| - Corner cases and bugs in rarely taken code paths | ||
| : A bug is a bug, it doesn't matter if the code where the bug sits is extremely unlikely to be executed, or if the calculated result of the code is unlikely to be used. The likelihood of failure doesn't change the type of the issue. It may however affect if we chose to fix it or not. |
Member
There was a problem hiding this comment.
Suggested change
| : A bug is a bug, it doesn't matter if the code where the bug sits is extremely unlikely to be executed, or if the calculated result of the code is unlikely to be used. The likelihood of failure doesn't change the type of the issue. It may however affect if we chose to fix it or not. | |
| : A bug is a bug, it doesn't matter if the code where the bug sits is extremely unlikely to be executed, or if the calculated result of the code is unlikely to be used. The likelihood of failure doesn't change the type of the issue. It may, however, affect if we chose to fix it or not. |
| : A bug is a bug, it doesn't matter if the code where the bug sits is extremely unlikely to be executed, or if the calculated result of the code is unlikely to be used. The likelihood of failure doesn't change the type of the issue. It may however affect if we chose to fix it or not. | ||
|
|
||
| - Performance issues | ||
| : Performance issues rarely break any specification, but in general these can be divided into two categories: Performance regressions (bugs) and Performance enhancements. If something has worse performance than it used to have, that is a regression. While if you are looking to improve performance of something that has not recently regressed, it's an enhancement. |
Member
There was a problem hiding this comment.
Suggested change
| : Performance issues rarely break any specification, but in general these can be divided into two categories: Performance regressions (bugs) and Performance enhancements. If something has worse performance than it used to have, that is a regression. While if you are looking to improve performance of something that has not recently regressed, it's an enhancement. | |
| : Performance issues rarely break any specification, but in general these can be divided into two categories: Performance regressions (bugs) and Performance enhancements. If something has worse performance than it used to have, it's a regression. While if you are looking to improve performance of something that has not recently regressed, it's an enhancement. |
dholmes-ora
reviewed
Mar 30, 2026
| : Provided you didn't just write the test and are doing test-driven development, a failing test is usually a sign of a bug. Something that used to work is now failing. The bug could be either in the JDK or in the test, but something is broken if a test is failing, and that should be classified as a bug. | ||
|
|
||
| - Is the existing code working as it was designed? | ||
| : If the code is doing what it was designed to do, and the design itself didn't have a bug, adapting code to changing circumstances should be considered enhancements. It's not a bug that we're not supporting a new version of an OS that didn't exist when the code was written. This includes cases where something that wasn't desired or required before has now become so. If something was deliberately left out for some acceptable reason, it would be an enhancement to add it later. |
Member
There was a problem hiding this comment.
Generally speaking code cleanups, performance improvements, increased debuggability (including new logging), are all enhancements to "code that was doing what it was designed to do" - but it may be worth mentioning them explicitly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some clarifications on how to determine if an issue is a bug or an enhancement.
Progress
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/guide.git pull/172/head:pull/172$ git checkout pull/172Update a local copy of the PR:
$ git checkout pull/172$ git pull https://git.openjdk.org/guide.git pull/172/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 172View PR using the GUI difftool:
$ git pr show -t 172Using diff file
Download this PR as a diff file:
https://git.openjdk.org/guide/pull/172.diff
Using Webrev
Link to Webrev Comment